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The 
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Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UH -Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology needed for JSC’s main missions, including 
administrative, engineering and science responsibilities. JSC agreed and entered into 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1 986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9- 1 6, computing and educational facilities are shared 
by the two institutions to conduct the research. 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/ JSC, and other research organizations. Within UH-Clear 
Lake, the mission is being implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involved via the “gateway” concept. UH-Clear 
Lake establishes relationships with other universities and research organizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICIS is to find the best match of sponsors, researchers and 
research objectives to advance knowledge in the computing and information 
sciences. Working jointly with NASA/JSC, RICIS advises on research needs, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NAS A/ JSC. 
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SECTION 1 

SUMMARY 


This document presents the preliminary version of expert 
knowledge for the onboard navigation ONAXT Ascent system.. Included 
is some brief background information alohg with the information 
describing the knowledge the system will /contain^ _ } t - ( U ' r 1 

I .±1 
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SECTION 2 

INTRODUCTION 


2 . 1 BACKGROUND 

Developing detailed requirements for an expert system often 
involves a series of meetings with various combinations of 
development team and expert personnel. These meetings review 
available information and discuss operations and functional 
processes of the proposed system. For the development of these 
Ascent requirements, such meetings were held. In addition, 
though, some information applicable to the Ascent phase of 
Shuttle flight were obtained from the Entry requirements noted in 
reference 1. 


2.2 SCOPE OF THIS DOCUMENT 

The target audience for this document is the knowledge domain 
expert. It will be a reflection of "what the system knows" in a 
form as close as possible to the expert's language. 

It is expected that changes to this document will be required in 
the future. In particular, efforts to integrate this document 
into console operator training and operations activities will 
subject the contents to the utmost scrutiny. 
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SECTION 3 

SYSTEM INFORMATION BASELINE 


The following subsections detail the various subsystem rule bases 
for the ONAV Ascent expert system. Each subsection is divided 
into five parts. 

a. General Information 

General information provides for background types of 
information or assumptions made in other parts. If no 
information is available or required to clarify general 
concepts and approaches, only the word -none- need be given. 
The intent is to provide any information that helps develop 
and clarify rules, concepts, or heuristics. 

b. Inputs 

Inputs should give descriptions of those data items or other 
information used to perform the processing in part c. If 
possible, the information sources should be specified as 
well . 

c. Rules/heuristics/concepts 

Rules/heuristics/concepts gives the specifications for the 
processing which must occur (or, in the case of rules, for 
the pieces of expertise which must be gathered) . The content 
may be rules, but may also consist of tables, figures, 
flowcharts, etc. as appropriate for specifying what is to be 
done. 

d. Outputs 

Outputs part should indicate what information is generated 
and available as a result of the processing performed. Any 
available destination information should also be included. 

e. Support Computations 

Support computations makes convenient the specification 
repetitive computations/manipulations needed as part of the 
processing activity, but which are not integral elements of 
the rules, heuristics, and concepts information. 
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3.1 INITIAL CONDITIONS 


a . General Information 

The selected atmosphere model must be checked as part 
of the expert system's initial processing. Information 
about the atmosphere model comes both from the ONAV 
operator (as an input) and from the telemetry downlist 
giving the onboard atmosphere selected by the crew. 

The primary avionics software system (PASS) and backup 
flight system (BFS) should be in Major Mode 304 after 
blackout. Ignore the major modes of systems which are 
not operating. 

b. Inputs 

1) Major mode PASS 

2) Major mode BFS 

3) BFS engage 

4) BFS NO GO (ONAV input) 

c. Rules/heuristics/concepts 

1) Engaged System 
IF 

- The BFS is engaged 
THEN 

- The BFS is the engaged system 
ELSE 

- The PASS is the engaged system 

2) System Availability (Part 1) 

IF 

- The BFS is engaged 
THEN 

- The BFS is the only system available 

3) System Availability (Part 2) 

IF 

- The BFS is not engaged 

- The BFS is NO GO 
THEN 

- The PASS is the only system available 

4) System Availability (Part 3) 

IF 

- The BFS is not engaged 

- The BFS is GO 
THEN 

- Both systems are available. 
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Outputs 


a) PASS sequencing problem 

b) BFS sequencing problem 

d) System availability 

e) Engaged system 

Support Computations 


None . 


3.2 TELEMETRY STATUS 


a. General Information 

The telemetry status tells the operator how much data 
is being downlisted. This is important because some 
variables are not available in low data rate. 

b. Inputs 

1) data-available 

2) high data rate 

3) low data rate 

c. Rules/Heuristics /Concepts 

1) Telemetry Status Change 
IF 

- the current status is not the same as the previous 
status 

THEN 

- notify the operator of a telemetry status change 

d. Outputs 

a) TLM status (high, low, or none) 

b) Status-change message 

e. Support Computations 
None 
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3.3 


LANDING SITE 


a . General Information 

It is important for the ground and onboard runways to 
match because delta state updates are computed in 
runway coordinates. 

b. Inputs 

1) I-load runway names and slots 

2) desired runway (name or slot number) (ONAV input) 

3) PASS runway (slot number) 

4) BFS runway (slot number) 

5) GND runway (name) 

6) system availability 

c. Rules/Heuristics /Concepts 

1) Check GND Runway 
IF 

- the GND runway (name) is not the same as the desired 
runway (name) 

THEN 

- notify operator that the selected GND runway is in 
error 

- recommend call to GDO to have trajectory change the 
GND runway 

2) Check Onboard Runway 
IF 

- for the available systems 

- the system runway (slot) is not the same as the 
desired runway (slot) 

THEN 

- notify operator that the system has selected the 
wrong runway 

- recommend call to crew to select proper runway 

d. Outputs 

1) runway selection error 

2) item entry for area selection 

3) item entry tor primary/ secondary runway 

e. Support Computations 

Calculate desired item entries to correctly select the 
runways . 

For actual and desired runways in the same area 
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desired = primary - spec 50 item 3 
desired = secondary - spec 50 item 4 


For actual and desired in different areas 

desired = primary - spec 50 item 41 + area 
desired = secondary - spec 50 item 41 + area 

where area = (desired slot + 1) /2 truncated to 
integer 


item 4 
an 
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3.4 INERTIAL MEASUREMENT UNITS (IMU) 

This section is divided up into 3 major parts Availability, Error 
Growth and Recommended Actions. 

3.4.1 Availability 

The purpose of this section is to determine which IMUs are 
available for use by Nav, or why an IMU is not available, and to 
note any changes in availability. Note that the check for good 
IMUs is to determine 1) how many IMU's can be used in the error 
detection and isolation sections, 2) if the IMU is independent of 
redundancy management (RM) , and 3) if it is not a check of which 
IMUs are available. 


3. 4. 1.1 PASS Availability 

a. General Information 


None 

b. Inputs 

1) IMU selection filter command 

2) commfault flags 

3) string commfault flags 

4) RM failure flags 

5) select/deselect flags 

6) BFS engage 

c. Rules /Heuristics /Concepts 

1) IMU Commfault PASS 
IF 

- The BFS is not engaged. 

- An IMU was not previously commfaulted in the 
PASS. 

- The commfault flag for that IMU is on in the 
PASS . 

THEN 

- Notify operator that an IMU is commfaulted 
(unless the whole string is commfaulted) . 

2) IMU commfault clear PASS (part 1) 

IF 

- The BFS is not engaged 

- An IMU has been unavailable to the PASS due to 
commfault. 

- The commfault flag for that IMU is off in the 
PASS. 
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- The fail flag or deselect flag for that IMU is 
on in the PASS. 

THEN 

- Notify operator that the commfault has cleared 
(unless it was a string commfault) 

- Conclude the IMU is unavailable to the PASS 
due to failure or deselect, whichever flag is 
on. 


3) IMU commfault clear PASS (part 2) 

IF 

- The BFS is not engaged. 

- An IMU has been unavailable to the PASS due to 
commfault . 

- The commfault flag for that IMU is off in the 
PASS. 

- The fail flag for that IMU is off in the PASS. 

- The deselect flag for that IMU is off in the 
PASS. 

THEN 

- Notify operator that the commfault has cleared 
(unless it was a string commfault) 

- Conclude the IMU is now available to the PASS. 

4) IMU failed PASS 
IF 

- The BFS is not engaged. 

- An IMU has been available to the PASS. 

- The fail flag for that IMU is on in the PASS. 
THEN 

- Notify operator of IMU failure. 

- Conclude the IMU is unavailable to the PASS due 
to failure. 

5) IMU deselected PASS 
IF 

- The BFS is not engaged. 

- An IMU has been available to the PASS. 

- The deselect flag for that IMU is on in the 
PASS. 

THEN 

- Notify operator of crew deselection. 

- Conclude the IMU is unavailable to the PASS 
due to deselect. 

6) IMU reselected PASS 
IF 

- The BFS is not engaged. 

- An IMU has bee unavailable to the PASS due to 
failure or deselect. 

- The fail flag for that IMU is off in the PASS. 

- The deselect flag for that IMU is off in the 
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PASS. 

THEN 

- Notify operator of crew reselection. 

- Conclude the IMU is now available to the PASS. 

7) Three good IMUs 
IF 

- The BFS is not engaged. 

- All three IMUs are not conunfaulted in the PASS. 

- All three IMUs are good. 

THEN 

- Conclude that there are three good IMUs in the 
PASS. 

8) Two good IMUs 
IF 

- The BFS is not engaged. 

- IMU A is not conunfaulted in the PASS. 

- IMU A is good. 

- IMU B is not conunfaulted in the PASS. 

- IMU B is good. 

- IMU C is conunfaulted in the PASS or suspect. 
THEN 

- Conclude we have two good IMUs in the PASS. 

9) One good IMU 
IF 

- The BFS is not engaged. 

- IMU A is not conunfaulted in the PASS . 

- T WU A is good. 

- -MU B is commf aulted in the PASS or suspect. 

- IMU C is conunfaulted in the PASS or suspect. 
THEN 

- Conclude we have one good IMU in the PASS . 

10) No good IMUs 
IF 

- The BFS is not engaged. 

- All three IMUs are conunfaulted in the PASS or 
suspect. 

THEN 

- Notify operator of IMU shortage in the PASS. 

- Conclude we have no good IMUs in the PASS . 

d. Outputs 

1) IMU good status 

2) IMU downmodes 

3) IMU upmodes 
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Support Computations 


e . 


None 


3.4. 1.2 BFS Availability 
a. General Information 

When the BFS is engaged, the expert system cannot keep 
track of I MU deselections and reselections except in certain 


situations . 



b. Inputs 

1) 

commfault flags 


2) 

string commfault 

flags 

3) 

hardware failure 

flags 

4) 

BFS IMU 


5) 

BFS NO GO 


6) 

BFS engaged 


7) 

IMU deselect flag 


c. Rules /Heuristics /Concep ts 


1) IMU Commfault BFS 

IF 

- The BFS is available. 

- An IMU was not previously comfaulted in the BFS. 

- The commfault flag for that IMU is on in the BFS 

THEN 

- Conclude the IMU is not available to the BFS due 
to commfault. 

- Notify operator of IMU commfault (unless the 
whole string is commfaulted) . 

2) IMU Commfault Clear BFS (Not Engaged) 

IF 

- The BFS is available. 

- The BFS is not engaged. 

- An IMU was unavailable to the BFS due to 
commfault. 

- The commfault flag for that IMU is off in the 
BFS. 

THEN 

- Conclude the IMU is available to the BFS ( if 
the fail flag is off) or unavailable due to 
failure (if the fail flag is on) . 

- Notify operator that commfault has been cleared 
(unless the whole string is commfaulted) . 
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3) IMU Commfault Clear BFS (Engaged) (Part 1) 

IF 

- The BFS is engaged 

- An IMU has been unavailable to the BFS due to 
commfault . 

- The commfault flag for that IMU is off in the 
BFS 

- The fail flag or deselect flag for that IMU is 
on in the BFS. 

THEN 

- Notify operator that the commfault has cleared 
(unless it was a string commfault) 

- Conclude the IMU is unavailable to the BFS due 
to failure or deselect, whichever flag is on. 

4) IMU Commfault Clear BFS (Engaged, Part 2) 

IF 

- The BFS is engaged 

- An IMU has been unavailable to the BFS due to 
commfault . 

- The commfault flag for that IMU is off in the 
BFS. 

- The fail flag for that IMU is off in the BFS. 

- The deselect flag for that IMU is off in the 
BFS. 

THEN 

- Notify operator that the commfault has cleared 
(unless it was a string commfault) 

- Conclude the IMU is now available to the BFS. 

5) IMU Failed BFS 

IF 

- The BFS is available. 

- An IMU was available to the BFS 

- The fail flag for that IMU is on in the BFS. 

THEN 

- Conclude the IMU is unavailable to the BFS due 
to failure. 

- Notify operator of IMU failure in the BFS. 

6) IMU Deselected BFS (part 1) (Not engaged) 

IF 

- The BFS is available. 

- The BFS was mid-value-selecting IMUs 

- All IMU commfault flags are off in the BFS. 

- All the IMU fail flags are off in the BFS 

- The BFS is prime selecting an IMU. 

THEN 

- Notify the operator that BFS has changed IMU 
status due to a crew action. 
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7) IMU Deselected BFS (part 2) not engaged 
IF 

- The BFS is Go. 

- The BFS is not engaged. 

- The BFS was prime selecting an IMU 

- The commfault flag for that IMU is off in the 
BFS. 

- The fail flag for that IMU is off in the BFS. 

- The BFS is now prime selecting a different IMU. 
THEN 

- Notify operator the formerly selected IMU has 
been deselected. 

8) IMU Deselected BFS (Engaged) 

IF 

- The BFS is Go. 

- The BFS is engaged. 

- An IMU has been available to the BFS 

- The deselect flag for that IMU is on the BFS. 
THEN 

- Notify operator of crew deselection in the BFS. 

- Conclude the IMU is unavailable to the BFS due 
to deselection. 

9) IMU reselection BFS (Engaged) 

IF 

- The BFS is engaged. 

- An IMU has been unavailable to the BFS due to 
failure or deselect. 

- The fail flag for that IMU is off in the BFS. 

- The deselect flag for that IMU is off in the 
BFS. 

THEN 

- Notify operator of crew reselection. 

- Conclude the IMU is now available to the BFS. 

10) IMU Change BFS 
IF 

- The BFS is Go. 

- The fail flag or commfault flag for an IMU is on 
in the BFS. 

- That IMU was the prime selected IMU or the BFS 
was mid-value selecting. 

THEN 

- Notify operator of a change in BFS IMU status 
due to commfault or failure. 

d. Outputs 

1) BFS downmodes 

2 ) BFS upmodes 

3) Changes in selected IMU in the BFS 
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Support Computations 


e . 


None 


3.4.2 Error Growth 

This section's purpose is to detect that an IMU is going 

bad, isolate which IMU is going bad, predict whether that IMU 
will fail in the next minute, and determine the magnitude of the 
IMU error. 

3.4.2. 1 Error Detection 

The comparisons in this section can be done with an IMU that is 
not available for NAV. This is only done so that if there is a 
problem at the two IMU level, the IMU not available to NAV can be 
used to help isolate the bad IMU in some circumstances. The term 
"valid" in the following sections means that an IMU can be used 
in comparisons with other IMUs; it does not refer to the overall 
health of an IMU or its suitability for use in the onboard 
system. 

All comparisons are either good, over half the RM threshold, or 
over the RM threshold. 

3.4.2. 1.1 Velocity Comparisons 

a. General Information 
None 

b. Inputs 

1) Velocity differences 

2) IMU status (PASS) 

3 ) BFS engage 

c. Rules /Heuristics /Concepts 

1) Valid Velocity 
IF 

- The BFS is not engaged. 

- An IMU is not commfaulted or failed. 

- That IMU is good or is suspect due to drift. 

THEN 

- Conclude that velocity comparisons with that 
IMU are valid. 

2) Invalid Velocity 
IF 
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- The BFS is not engaged. 

- An IMU is commfaulted, failed or is suspect due 
to anything but drift. 

THEN 

- Conclude that velocity comparisons with that 
IMU are invalid. 

3) Velocity Comparison (part 1) 

IF 

- The BFS is not engaged. 

- IMU A is not commfaulted or failed 

- IMU B velocity is valid 

- Velocity comparison A-B is different from IMU 
A's earlier velocity comparison status. 

- IMU C velocity is invalid. 

THEN 

- Change IMU A’s velocity comparison status to 
current A-B comparison status. 

4) Velocity Comparison (part 2) 

IF 

- The BFS is not engaged. 

- IMU A is not commfaulted or failed 

- IMU B velocity is valid 

- Velocity comparison A-B is some status (call it 
status-1) 

- IMU C velocity is valid 

- Velocity comparison A-C is some status (call it 
status-2 

- The smaller of status-1 and status-2 s 
different from IMU A's earlier velocity 
comparison status 

THEN 

- Change IMU A's velocity comparison status to the 
smaller of status-1 and status-2. 


d. Outputs 

1) Velocity miscompare indicators 

e. Support Computations 

None 


3. 4. 2. 1.2 Attitude Comparisons 
a. General Information 

None 


b. 


Inputs 


1) Gyro differences (RSS of gyro errors on 1417) 

2) IMU status (PASS) 

3) BFS engage 

c. Rules/Heuristics/Concepts 

1) Valid Attitude 
IF 

- The BFS is not engaged 

- An IMU is not commfaulted or failed 

- That IMU is good or is suspect due to 
accelerometer bias. 

THEN 

- Conclude that attitude comparisons with that 
IMU are valid. 

2) Invalid Attitude 
IF 

- The BFS is not engaged 

- An IMU is commfaulted, failed or is suspect due 
to anything but bias. 

THEN 

- Conclude that attitude comparisons with that 
IMU are invalid. 

3) Attitude Comparison (part 1) 

IF 

- The BFS is not engaged 

- IMU A is not commfaulted or failed 

- IMU B attitude is valid 

- Attitude comparison A-B is different from IMU 
A's earlier attitude comparison status 

- IMU C attitude is invalid 
THEN 

- Change IMU A's attitude comparison status to 
current A-B comparison status. 

4) Attitude Comparison (part 2) 

IF 

- IMU A is not commfaulted or failed 

- IMU B attitude is valid 

- Attitude comparison A-B is some status (call it 
status-1) 

- IMU C attitude is valid 

- Attitude comparison A-C is some status (call it 
status-2) 

- The smaller of status-1 and status-2 is 
different from IMU A's earlier attitude 
comparison status. 

THEN 

- Change IMU A's attitude comparison status to the 
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smaller of status-1 and status-2. 


d. Outputs 

1) Attitude miscompare indicators 

e . Support Computations 

If you use RSS of gyro errors from 1417 and calculate threshold 
in the preprocessor, then you can use these values exactly as the 
ATT differences in the Entry system. 

Note: you must store the OPS 9/1 transition times for PASS and 

BFS . 


3. 4. 2. 1.3 ACC Comparisons 

a. General Information 

None 

b. Inputs 

1) ACC differences 

2) IMU availability (PASS) 

3) reference IMU 

4) ACC delta-t 

c. Rules /Heuristics /Concepts 

1) Valid to use ACC comparison 
IF 

- The BFS is not engaged 

- The ACC delta-t > 30 seconds 
THEN 

- Valid to use ACC comparison 

2) Valid ACC 
IF 

- An IMU is not commfaulted or failed 

- That IMU is good or is suspect due to resolver. 
THEN 

- Conclude that ACC comparisons with that IMU are 
valid. 

3) Invalid ACC 
IF 

- An IMU is commfaulted, failed or is suspect due 
to anything but resolver. 

THEN 

- Conclude that ACC comparisons with that IMU are 
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invalid . 


4) ACC Comparison (part 1) 

IF 

- IMU A is not commfaulted or failed 

- IMU B ACC is valid 

- Worst axis ACC comparison A-B is different from 
IMU A's earlier ACC comparison status. 

- IMU C ACC is invalid 
THEN 

- Change IMU A's ACC comparison status to current 
A-B comparison status. 

5) ACC Comparison (part 2) 

IF 

- IMU A is not commfaulted or failed 

- IMU B ACC is valid 

- Worst axis ACC comparison A-B is some status 
(call it status-1) . 

- IMU C ACC is valid 

- Worst axis ACC comparison A-C is some status 
(call it status-2) . 

- The smaller of status-1 and status-2 is 
different from IMU A's earlier ACC comparison 
status. 

THEN 

- Change IMU A's ACC comparison status to the 
smaller of status-1 and status-2. 

6) Worst Comparison 

IF 

- Exactly 2 good IMUs are available 

- Those 2 IMUs disagree in any way. 

THEN 

- Conclude that 2-level isolation must be used to 
determine which of the 2 IMUs has a problem. 


d. Outputs 

1) ACC miscompare indicators 

e. Support Computations 

None 


3. 4. 2. 2 Error Isolation 
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3. 4. 2. 2.1 Three-level Isolation 

a. General Information 

At the 3-level with no suspect IMU's, use the following fault 
matrix, with a miscompare indicated for an IMU if it disagrees 
with both other IMUs. 

A table drawn up to categorize the type of error that probably 
exists when problems have been isolated to a component are as 
follows : 


vel 

att 

acc 


0 

0 

y 


0 

y 

0 


y 

o 

o 


y 

y 

o 


y 

o 

y 


o 

y 

y 


y 

y 

y 


\ 

> — isolated or not 

/ 


| \ att and vel problems 

\_ drift 

\ bias 

resolver 

\ probably velocity 

\ probably attitude 

probably attitude 


note: acc means either acc-x, acc-y, or acc-z 

0 means O.K., y means yes there is a problem 
(i.e., an IMU miscompared with both other IMU's). 


b. Inputs 


1) velocity miscompare indicators 

2) attitude miscompare indicators 

3) ACC miscompare indicators 

4) IMU availability (PASS) 

c. Rules /Heuristics/Concepts 

1) Three Level Component Isolation 
IF 

- The BFS is not engaged 

- There are 3 good IMUs 

- An IMU disagrees with the other 2 IMUs. 

THEN 

- Use the fault matrix to determine the problem 
with the IMU. 

- Notify operator of an IMU problem. 

d. Outputs 


1) IMU quality rating 



Support Computations 


e . 


None 


3. 4. 2. 2. 2 Two-level Isolation 

a. General Information 

When a miscompare exists between the two remaining good I MU 1 s 
there are four methods ^.hat can be used to determine which I MU 
has the problem. The results of these methods is combined via a 
voting scheme. 

Method 1) Check A/GND and B/GND (where A and B are the two 
remaining IMUs) to see if exactly one is over the threshold. If 
so, vote 1 for that IMU; otherwise vote zero for both. 

Method 2) Check PASS and BFS state vectors. If BFS better than 
PASS, then BFS IMU better and vote 2 for other IMU. Else, if BFS 
worse than PASS, then PASS IMU better and vote 2 for BFS IMU. 
Else vote 0 for both. 

Method 3) Let A be the reference IMU for the ACC comparison. If 
ACC miscompares are in the X-Y plane or the Z axis (but not both) 
then vote 1 for A. 

Method 4) : you can ditto method 3 for the gyro compare. 

If either IMU outvotes the other by 2 or more, then that IMU is 
declared suspect. 

Once the IMU has been isolated, use comparisons with the other 
IMU and the fault matrix in section 3. 4. 2. 2. 1.1 to determine the 
problem with the bad IMU. 

b. Inputs 


1) 1,2,3/GND IMU differences 

2) PASS and BFS state errors 

3) velocity miscompare indicators 

4) ACC miscompare indicators 

5) IMU availability (PASS) 

6) reference IMU 

7) IMU quality rating 

8) HSTD status 

9) BFS selected IMU 

c. Rules/Heuristics /Concepts 

1) Two Level GND Comparison (velocity) 
IF 
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been detected 


- HSTD is good 

- An error between IMUs A and B has 
at the two level. 

- Worst axis GND-IMUA comparison is some status 
(call it status-a) . 

- Worst axis GND-IMUB comparison is some status 
(call it status-b) . 

- GND-IMU comparison has not yet voted. 

THEN 

- When status-a = status-b, vote 0 for both IMUs. 

- Otherwise, vote 1 for the IMU with the larger 
difference, and 0 for the other IMU. 

2) Two Level GND Can't Vote 

IF 

- An error between IMUs A and B has been detected 
at the two level. 

- The HSTD is not good. 

- GND-IMU comparison has not voted yet. 

THEN 

- Vote 0 for IMUs A and B. 

3) Two Level State Comparison 

IF 

- HSTD is good 

- An error between IMUs A and B has been detected 
at the two level. 

- GND-PASS comparison is some status 
(call it status-a) . 

- GND-BFS comparison is some status 
(call it status-b) . 

- State comparison has not voted yet. 

THEN 

- When status-a = status-b, vote 0 for both IMUs. 

- Otherwise, vote 2 for the IMU with the larger 
difference, and 0 for the other IMU. 

4) Two Level ACC Comparison 

IF 

- An error between IMUs A and B has been detected 
at the two level. 

- IMU A is the reference for ACC comparisons. 

- X-axis ACC comparisons A-B is some status (call 
it status-x) . 

- Y-axis ACC comparisons A-B is some status (call 
it status-y) . 

- Z-axis ACC comparisons A-B is some status (call 
it status-z) . 

- ACC comparison has not voted yet. 

THEN 

- If status-x, status-y, and status-z indicate the 
error lies in the x-y plane or z-axis of IMU A, 
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vote 1 for IMU A; otherwise, vote 0 for IMU A. 

- Vote 0 for IMU B. 

5) Two Level ACC Can't Vote 

IF 

- An error between IMUs A and B has been detected 
at the 2 level. 

- Neither A nor B is the ACC reference IMU. 

- ACC comparison has not voted yet. 

THEN 

- Vote 0 for both IMUs A and B. 

6) Two Level Vote Count 

IF 

- GND-IMU comparison rules have cast vl votes for 
an IMU. 

- State comparison rules have cast v2 votes 
for that IMU. 

- ACC comparison rules have cast v3 votes for that 
IMU. 

- Partial IMU comparison rules have cast v4 votes 
for that IMU. 

THEN 

- Compute vote total for the IMU as vl+v2+v3+v4. 

7) Two level IMU Isolation 

IF 

- Votes for IMU A exceeded votes for IMU B by 2 
or more. 

THEN 

- Conclude IMU A has an error. 

8) Two Level Component Isolation 

IF 

- An error between IMUs A and B has been detected 
at the 2 level. 

- IMU A is the one with the problem. 

THEN 

- Use the fault matrix to determine the problem 
with IMU A. 

- Notify operator of the problem. 

- Clear the miscompare indications for IMU B. 

9) Two level Can't Isolate 

IF 

- Votes for IMU A did not exceed votes for IMU B 
by 2 or more. 

- Votes for IMU B did not exceed votes for IMU A 
by 2 or more. 

THEN 

- Notify operator that the IMU error cannot be 
isolated. 
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10) Change IMU Quality 

IF 

- An IMU was previously diagnosed as having a 
problem. 

- That IMU's comparisons now indicate a different 
diagnosis 

- The new indicated diagnosis is a bias, resolver 
or drift, or no problem at all. 

THEN 

- Update the IMU's quality rating to reflect the 
new diagnosis. 

- Notify the operator of the new diagnosis. 

d. Outputs 

1) IMU quality rating 

e. Support Computations 

None 


3 . 4 . 2 . 3 Error Magnitude 

a. General Information 

It is desirable for notification messages to contain the 
following information: who, why and magnitude. For example, "IMU# 
<who> has a <why> of <magnitude>; It <should/should not> fail". 
Magnitude information is used to make the "should/should not" 
determination . 

Algorithms exist to do this, including using the largest compare 
(largest valid compare) . 

b. Inputs 

1) IMU quality rating 

2) velocity differences 

3) attitude differences 

c. Rules /Heuristics /Concepts 

1) Bias Magnitude 
IF 

- IMU A has an accelerometer bias. 

- IMU B velocity is valid. 

- IMU C velocity is invalid or IMU C has a lower 
number than B. 

THEN 

- Compute the magnitude of the bias using the 
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A - B pairwise velocity comparison. 

- Notify operator of the magnitude of the bias. 

2) Resolver Magnitude 
IF 

- IMU A has a resolver error. 

- IMU B attitude is valid. 

- IMU C attitude is invalid or IMU C has a lower 
number than B. 

THEN 

- Compute the magnitude of the resolver error 
using the A - B pairwise attitude comparison. 

- Notify operator of the magnitude of the resolver 
error. 

3) Drift Magnitude 
IF 

- IMU A has a drift. 

- IMU B attitude is valid. 

- IMU C attitude is invalid or IMU C has a lower 
number than B. 

THEN 

- Compute magnitude of the drift using the A - B 
pairwise attitude comparison. 

- Notify operator of the magnitude of the drift. 

d. Outputs 

1) accelerometer bias 

2) drift rate 

3) resolver error 

e . Support Computations 

For velocity (bias) , 
magnitude = 2023 * 

( SQRT largest-val id-velocity-di f f erence ) 
(units of micro-g's) 

For attitude (resolver) , 
magnitude = deg/rad * 

(SQRT largest-valid-attitude-diff erence) 
(units in degrees) 

For attitude (drift) , 

magnitude = sec/hour * (resolver-t - resolver-o) / 
(t - t-o) 

(units in deg/hr) 

o is at some initial time, (e.g. , deorbit prep) . 
resolver-t and resolver-o are computed by the 
resolver magnitude equation above. 


3.4 


17 


It should be noted that at the two level, for example, 
if IMU 1 is failed, then 2-3 is the compare to use. 


3. 4. 2. 4 Failure Prediction 


a. General Information 

Failure prediction is based on miscompares which exceed an RM 
threshold. Recall that error detection and isolation is based on 
miscomparisons exceeding half of an RM threshold. 

b. Inputs 

1) IMU selection filter command 

2) velocity differences 

3) attitude differences (RSS of gyro compares, with 

threshold calculated in preprocessor) 

c. Rules/Heuristics/Concepts 

1) Three Level Failure Prediction 
IF 

- Onboard IMU RM is at the 3 level . 

- Exactly two pairwise differences exceed the 
fail threshold in either velocity or attitude. 

- A failure has not yet been predicted. 

THEN 

- Predict RM will fail the IMU common to the 
two pairs that exceed the threshold. 

2) Three Level No Failure Prediction 
IF 

- Onboard IMU RM is at the 3 level . 

- All 3 pairwise differences in velocity or 
attitude exceed the fail threshold. 

- A failure has not yet been predicted. 

THEN 

- Predict IMU RM will not take any action. 

3) Two Level Failure Prediction 
IF 

- Onboard IMU RM is at the 2 level 

- IMU A is available but not good. 

- IMU B is available and good. 

- IMUs A and B differ in velocity or attitude 
by more than some threshold. 

- A failure has not yet been predicted. 

THEN 

- Predict an RM action, and indicate IMU A is the 
one that needs to be failed. 



4) Check bite 

When at 2 level and IMU A has bite and I MU B is 
bad, then predict that RM will fail the wrong IMU. 
This must consider the possibility of needing 
a test on previous rules in order to know that IMU 
RM will do anything at all. 

d. Outputs 

1) predicted IMU failure 

e. Support Computations 

None 


3.4.3 Recommended Actions 

3. 4. 3.1 PASS IMU Actions 

a. General Information 


None 

b. Inputs 

1) IMU availability (PASS) 

2) IMU quality rating 

3) attitude IMU 

c. P ules /Heuristics /Concepts 

1) Reselect IMU 
IF 

- An IMU is unavailable to the PASS due to 
deselection. 

- That IMU is good. 

THEN 

- Recommend that IMU be reselected ( after zero 
delta state if 3-state nav is still active) . 

2) Help IMU Dilemma 
IF 

- IMU RM is in dilemma. 

- IMU A is available to the PASS and good. 

- IMU B is available to the PASS and not good. 
THEN 

- Recommend deselecting IMU B. 

3) Can't Help IMU Dilemma 
IF 
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- I MU RM is in dilemma 

- IMU A is available to the PASS. 

- IMU B is available to the PASS. 

- Either A and B are both good or A and B are 
both not good. 

THEN 

- Notify operator that dilemma cannot be resolved. 


4) Incorrect IMU failure 
IF 

- IMU A is unavailable to the PASS due to failure 

- IMU A is good. 

- IMU B is available to the PASS. 

- IMU B is not good. 

THEN 

- Notify operator of incorrect RM isolation and 
recommend switching to IMU A. 

5) Deselect Commfaulted IMU 
IF 

- An IMU is unavailable to the PASS due to 
commfault for some amount of time. 

- That IMU has not been deselected. 

THEN 

- Recommend deselecting the IMU. 

d. Outputs 

1) PASS deselect/reselect messages 

e . Support Computations 

None 


3. 4. 3. 2 BFS IMU Actions 

a . General Information 

A general rule for BFS IMUs is that an IMU should not be 
available in BFS if not available in PASS, except if its the only 
one left in BFS. 

b. Inputs 

1) IMU availability (BFS) 

2) BFS IMU 

3) IMU quality rating 

c. Rules /Heuristics /Concepts 
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1) Deselect IMU in BFS 
IF 

- IMU A is not available to the PASS. 

- IMU A is available to the BFS. 

- IMU B is available to the BFS. 

THEN 

- Recommend deselecting IMU A in the BFS. 

2) No BFS IMUs 
IF 

- The BFS is on IMU A. 

- IMU A is unavailable to the PASS. 

- Neither IMUs B or C are available to the BFS. 
THEN 

- Notify operator of IMU shortage in the BFS. 

3) Change BFS IMU (part 1) 

IF 

- The BFS is on IMU A. 

- IMU A is not good. 

- IMU A is available to the PASS. 

- IMU B is available to the BFS. 

- IMU B is good. 

- Either IMU C is unavailable to the BFS or has 
a higher number than IMU B. 

THEN 

- Recommend deselect/reselect IMU A to put the 
BFS on IMU B. 

4) Change BFS IMU (part 2) 

IF 

- The BFS is on IMU A. 

- IMU A is not good. 

- IMU B is available to the BFS and is good. 

- IMU C is available to the BFS but is not good 

- IMU C has a lower number than IMU B. 

THEN 

- Recommend deselect/reselect IMU's A and C to put 
the BFS on IMU B. 

Output 

1) BFS deselect/reselect messages 
Support Computations 


None 


3 . 5 STATE VECTORS 


3.5.1 State Error Status 

a . General Information 

Don't do any NAV checking until NAV init. 

IF GROUND COMPARES AVAILABLE 
Use this table [see Note #3] 


GND-PRI 

GND-BFS 

PFS-BFS 

CALL TO GUIDANCE 

> 

UPDATE 

LIMIT 

> 

XFER 

LIMIT 

N/A 

PASS has (error) [see Note 
BFS has (error) 

Need ST. VECTOR UPDATE; 

No XFER required 

ii 

> 

GAL 

N/A 

PASS has (error) 

BFS has (error) 

Need ST. VECTOR UPDATE; 
No XFER required 

ii 

IN 

LIMITS 

N/A 

PASS has (error) 

BFS is GO 

Need ST. VECTOR UPDATE; NO 
XFER needed 

> 

GUID 

ADV. 

> 

XFER 

LIMIT 

>GAL 

PASS has (error) [see Note 
BFS has (error) 

Need ST. VECTOR XFER 

LIMIT 

(GAL) 

ii 

<GAL 

PASS has (error) [see Note 
BFS has (error) 

No XFER is needed 

ii 

> 

GAL 

N/A 

PASS has (error) 
BFS has (error) 

ii 

IN 

LIMITS 

N/A 

PASS has (error) 
BFS is GO 

IN 

LIMIT 

> 

XFER 

LIMITS 

N/A 

PASS is GO 
BFS has (error) 

Need ST. VECTOR XFER 

ii 

> 

GAL 

N/A 

PASS is GO 
BFS has (error) 

ii 

IN 

LIMITS 

N/A 

PASS and 
BFS ARE GO 



Note #1: Unless the GND-PRI is about to violate the update 

criteria the transfer will take out a significant 
amount of error in the BFS. Otherwise it might be 
better to wait for the GND-PRI error to violate the 
update criteria and treat it appropriately. 

Note #2: The error taken out by a transfer is not significant in 

this case. 

Note #3: Prior to Meco 

DELTA STATE 
Post Meco 
WHOLE STATE 


IF GROUND COMPARES NOT AVAILABLE 
Use this table 


PFS-BFS 

IMU-SITUATION 

> 

2 IMU Level 

XFER 

One BAD IMU 

LIMITS 

BFS on Good One 

ii 

ALL 

OTHER CASES 

> 

GAL 

N/A 

IN 

LIMITS 

N/A 



CALL IQ 

GUIDANCE 


(error) 

between 

PASS 

and 

BFS 

BFS better than 

PASS 

so 


NO XFER 

needed 

[see ; 

Note 

#4] 

(error) 

between 

PASS 

and 

BFS 


need state vector transfer 
(error) between PASS and BFS 

PASS and BFS are TRACKING 


Note 4: A transfer would make the BFS as bad as the PASS 


when 


when 


VERIFY STATE VECTOR UPDATE 
GND-PRI-> ' 0 

call "Guidance the update is onboard" 

VERIFY STATE VECTOR TRANSFER 

GND-BFS ' GND-PRI or PFS-BFS * 0 
CALL "Guidance we see the transfer" 
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Inputs 


1) HSTD health 

2) GND-PASS 

3) GND-BFS 

4) PASS-BFS 

5) System availability 

6) DT (PASS - BFS state vector time tag difference) 

7) NAV init 

Rules/Heuristics/Concepts 

1) NAV Init 
If 

- NAV init = off 

- PASS-BFS = bad previously 

- PASS-BFS now good 
THEN 

- NAV init = on 

- Notify operator of nav init 

2) State error change 
IF 

- For available systems 

- The system worst axis error is different 
from what it was on the previous cycle. 

THEN 

- Record the new worst axis status. 

3) Report state error 
IF 

- More than 60 seconds has elapsed since the last 
report . 

THEN 

- Report the error on every axis whose status is 
the same as the worst axis. 

4) PASS and BFS timing problem 

IF 

- the HSTD is not good 

- both systems are available 

- the DT is > j 0.0003 [ 

THEN 

- there is a timing problem between the PASS and 
BFS 

5) PASS BFS error change 
IF 

- Both systems are available 

- No timing problem between the PASS and the BFS 

- The HSTD is not good 

- The PASS-BFS worst axis error is different from 
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what it was on the previous cycle. 

THEN 

- Record the new worst axis status. 

6) Report PASS BFS error 
IF 

- both systems are available 

- No timing problem between the PASS and the BFS 

- The HSTD is not good. 

- More than 60 seconds has elapsed since the last 
report of PASS-BFS errors. 

THEN 

- Report the error on every axis whose status is 
the same as the worst axis. 

d. Outputs 

1) state error messages 

2) timing problem between PASS and BFS 

e. Support Computations 


following 

table 

is valid 

for GND- 

-PASS, GND- 

■BFS, and 

PASS-BFS 

PASS 

PRE 

LIFTOFF 

L/0 

- MECO 

POST 

MECO 




(GNDFIL-PAS) 

(GNDEPH-PAS ) 


GAL 

UPDATE 

GAL 

UPDATE 

GAL 

UPDATE 

u 

N/A 

N/A 

3K 

6K 

6K 

12K 

V 



3K 

6K 

24K 

48K 

w 



3K 

6K 

24K 

48K 

uD 



20 

50 * 

20 

50 * 

vD 



20 

40 * 

20 

40 * 

wD 



20 

50 

20 

50 
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BFS 

PRE LIFTOFF 

L/0 - MECO 
(GNDFIL-BFS) 

POST MECO 
(GNDEPH-BFS) 

- • 


GAL XFER 

GAL 

XFER 

GAL 

XFER 


u 

N/A N/A 

3K 

6K 

6K 

12K 


V 


3K 

6K 

24K 

48K 


w 


3K 

6K 

24K 

48K 

— 

uD 


15 

50 * 

15 

50 * 


vD 


15 

40 * 

15 

40 * 


wD 


15 

50 

15 

50 


If NO ground 

compares 






PFS-BFS 

PRE LIFTOFF 

L/0 

- MECO 

POST 

MECO 



GAL XFER 

GAL 

XFER 

GAL 

XFER 


X 

N/A N/A 

3K 

6K 

24K 

48K 

— - 

y 


3K 

6K 

24K 

48K 


z 


3K 

6K 

6K 

12K 

n _- 

XD 


20 

50 

20 

50 


yD 


20 

40 

20 

40 


ZD 


20 

50 

20 

50 


If any value > GAL limit 
I GOTO STATE ERROR (Section 7.0) 


R: o GAL-Guidance Advisory Limit -> means that the error is 

significant enough to inform the Guidance officer. 

* o update limits are per flight rules. 

o Guido relies on ONAV for all information on the BFS; 
therefore, when possible give as much information as 
possible when making calls as the situation allows. 
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i.e., it is growing steadily or we expect it to degrade 
quickly. 

o NOTE The GNDEPH-PAS AND THE GNDEPH-BFS algorithms are 
not valid during burns due to the way ground nav 
models the burns. 


Results from this table will be such that: 

GRND-PASS is = good/suspect/ over 
GRND-BFS is = good/suspect/ over 
PASS-BFS is = good/suspect/ over 
All units are in feet and feet/sec . 


3.5.2 Delta State Update 

a . General Information 


Note that delta state is done before MECo and a whole state is 
done after MECO. 

b. Inputs 

1) HSTD status 

2) GND-PASS 

3) GND-BFS 

4) engaged system 

5) Doing a Delta state (ONAV input) 

c. Rules /Heuristics /Concepts 

1) Need delta state 
IF 

- For the engaged system 

- GND-System shows the System is above the update 
limits. 

THEN 

- a delta state is needed. 

2) OK for Delta state (Part 1) 

IF 

- a delta state is needed 

- GND and engaged system runways are the same 
THEN 

- recommend a delta state update 

3) Not OK for Delta State 
IF 

- a delta state is needed 

- the GND and engaged system runways are not the 
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same 

THEN 

- notify operator that a delta state is needed but 
there is runway mismatch 


4) DELTA STATE is in BFS 
IF 

- BFS engaged 

- delta-state in progress 

- GND-system errors previously not close to zero 

- GND-system errors are now close to zero 
THEN 

- Report that state update is in 

d. Outputs 

1) delta-state recommendation 

2) delta state no go due to runway mismatch 

3) Delta state in 

e. Support Computations 

"Previously not close to zero" and "are now close to zero" refer 
to a comparison between the current measurement and previous 
measurement. 


3.5.3 BFS Transfer 

a. General Information 

None 

b. Inputs 

1) HSTD status 

2) GND-BFS 

3) System availability 

4) PASS state error status 

5) PASS - BFS state error status 

6) PASS - BFS timing problem status 

7) delta-state in progress 

c. Rules /Heuristics /Concepts 

1) Need transfer (part 1) 

IF 

- good HSTD 

- both systems available 


- GND-BFS > update limit 

- PASS state error status is good 
THEN 

- recommend a transfer to the BFS 

2) Need transfer (Part 2) 

IF 

- good HSTD 

- both systems available 

- GND-BFS > update limit 

- PASS state error status is suspect 

- no PASS-BFS timing problem 

- PASS-BFS status is suspect or bad 
THEN 

- recommend a transfer to the BFS 

3) Need transfer (Part 3) 

IF 

- the HSTD is good 

- both systems are available 

- GND-BFS > update limit 

- delta-state in progress 
THEN 

- notify operator that a transfer will be needed 
after the state vector update 

4) Do not do a transfer (Part 1) 

IF 

- the HSTD is good 

- both systems are available 

- GND-BFS > update limit 

- Pass state error status is suspect 

- Pass-BFS state error status is good 
THEN 

- notify operator that no transfer is needed 
because it won't improve the BFS by much. 

5) Do not do a transfer (Part 2) 

IF 

- The HSTD is good 

- both systems are available 

- GND-BFS > update limit 

- Pass state error status is suspect 

- There is a a PASS-BFS timing problem 
THEN 

- notify operator that NO transfer is needed 
because we are not sure how much it will improve 
the BFS vector. 

6) Transfer when no HSTD 
IF 

- the HSTD is not available 
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- both systems are available 

- PASS has at least one good IMU 

- BFS prime selecting bad or suspect IMU 

- PASS-BFS error is bad 

- No PASS-BFS timing problem 
THEN 

- recommend a transfer to the BFS (any other 
situation could possibly corrupt the BFS with a 
transfer) 


d. Outputs 

1) transfer recommendation 

2) confirmation of transfer 

e . Support Computations 

None 
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3.6 HIGH SPEED TRAJECTORY DETERMINATOR (HSTD) 

a . General Information 


These rules have the task of determining the status of the HSTD 
state vector. These rules depend primarily on operator input. The 
rules can detect when the filter is stopped, and they can detect 
some situations where the filter is not converged. In addition, 
the operator can indicate when the filter is bad. The operator 
must specify when the filter is good; the rules never do that 
automatically . 

Overall rationale; better to assume ground is bad and not make 
some recommendations, rather than assume ground is good 

and encounter bad recommendations. The issue is to keep 
consistency between ONAV expert system recommendations and ground 
status (which is available only over the "loop”.) 

b. Inputs 

1) operator input, 

2) ground nav expert system (not yet available) 

3) internal rules in the ONAV expert system. 

c. Rules /Heuristics/Concepts 

1) start HSTD 
IF 

- the HSTD has not been running 

- the "stopped" indicator is off 
THEN 

- conclude the HSTD is running but has not converged 

2) HSTD bad 
IF 

- the HSTD was good 

- the operator entered the HSTD bad indicator 
THEN 

- conclude the HSTD is bad (not converged) 

3) HSTD good 
IF 

- the HSTD was bad 

- the operator entered the HSTD good indicator 

- at least 10 seconds have elapsed since last restart 
THEN 

- conclude HSTD is good 
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4) HSTD stopped 
IF 

- the HSTD is running 

- the stopped indicator is on 
THEN 

- conclude the HSTD has been stopped 

5) HSTD editing 
IF 

- the HSTD was good 

- less than 3 stations are being processed 

- a given station is not being excluded 

- there is data coming from that station 

- at least one good measurement of a given type was 
available from that station 

- all of the measurements of that type from that 
station were edited by the filter 

THEN 

- conclude the HSTD is bad 

6) HSTD prop 
IF 

- the HSTD was good 

- the prop flag is on 
THEN 

- conclude the HSTD is bad 

7) HSTD covariance 
IF 

- the HSTD was good 

- the RSS position or velocity covariance diagonals 
are too large 

THEN 

- conclude the HSTD is bad 

8) HSTD restart 
IF 

- the HSTD restart flag is on 
THEN 

- conclude the HSTD is bad 

- record the current time as the time of the last 
restart 

9) no ground data 
IF 
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- no ground data available 
THEN 

- Make a statement on NAV as it relates to BFS 
transfers . 


d. Outputs 

1) HSTD Health (Good, bad, not running, not available) 

e . Support Computations 

None 
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3.7 BFS ALTITUDE CHECK 


a . General Information 

The first check below gives an indication of how the IMU's are 
behaving. After OPS 9/1 transition, the IMU is being compensated 
for the rotation of the earth. However, there is no compensation 
along the up axis so that IMU's are drifting freely along that 
axis . 

The BFS state vector is initialized at OPS 9/1 transition. The 
BFS state vector is propagated using IMU data. The position and 
velocity (PAD 90 vector) of the vehicle on the pad is known. The 
BFS state vector is compared to the PAD 90 vector. The altitude 
component of this error is directly related to the performance of 
the IMU's in up axis. Since the IMU's are not being compensated 
in that axis, we have an insight into how well the IMU's are 
performing. 

b. Inputs 

To be determined. 

c. Rules /Heuristics/Concepts 

1) Continuous Pre-launch Monitoring of BFS Altitude 
IF 

- the BFS altitude is greater than 1 sigma 
THEN 

- conclude that the IMU's are greater than 1 sigma, 
even though there is nothing that can be done about 
it by ONAV. 

2) PAD 90 Z axis check 
IF 

- PAD 90 Z (pos and vel of vehicle on the pad) is less 
than U from the table (see table referenced on p.3-6 
of the ONAV/ascent handbook) . 

THEN 

- notify operator that the BFS altitude is less than 
one sigma 

ELSE 

- notify operator that the BFS altitude is <tbd> sigma. 

d. Outputs 

1) BFS altitude greater than 1 sigma 

e. Support Computations 

Compute delta-time from OPS 9/1 transition in the BFS. 
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